FIG. 1 shows a typical electronic system, such as the electronic system of a vehicle, comprising a plurality of processing systems lox, such as embedded systems or integrated circuits, e.g., a Field Programmable Gate Array (FPGA), Digital Signal Processor (DSP) or a micro-controller (e.g., dedicated to the automotive market).
For example, in FIG. 1 are shown three processing systems 101, 102 and 103 connected through a suitable communication system 20. For example, the communication system may include a vehicle control bus, such as a Controller Area Network (CAN) bus, and possibly a multimedia bus, such as a Media Oriented Systems Transport (MOST) bus, connected to vehicle control bus via a gateway. Typically, the processing systems lox are located at different positions of the vehicle and may include, e.g., an Engine Control Unit (ECU), a Transmission Control Unit (TCU), an Anti-lock Braking System (ABS), a body control modules (BCM), and/or a navigation and/or multimedia audio system.
Future generation of processing systems, in particular micro-controllers dedicated to automotive applications, will exhibit a significant increase in complexity, mainly due to the increasing number of functionalities (such as new protocols, new features, etc.) and to the tight constraints concerning the operation conditions of the system (such as lower power consumption, increased calculation power and speed, etc.). For example, complexity is expected to increase in particular in the context of the forthcoming Car2X and autonomous driving world, because safety and security of the processing systems 10x will become more and more relevant.
Usually, safety is intended to guarantee the functionality in case of both random and systematic faults, e.g., due to the corruption of “functional-critical” configuration data programmed during the production of the micro-controller, such as calibration data or other types of configuration data used to trim and/or configure the device functionalities. For example, the specification ISO 26262 dictates a complete process and the requirements to achieve a functionality being compliant within the chosen safety goals.
Conversely, security is intended to guarantee the protection of the internal resources against malicious attacks, which, for example, might lead to the corruption of the above mentioned data. For example, encryption of the communications between the various systems will become mandatory for the upcoming Car2X and autonomous driving scenario.
Thus, while achieving different and possible diverging goals, safety and security should be treated in conjunction. For example, this becomes evident when considering a possible abnormal behavior of a processing system 10x of the vehicle. From a safety point of view, the micro-controller should still be able to operate permitting an operation of the vehicle, even in a “degraded” mode. Conversely, from a security point of view, it might be advisable to stop the car, e.g., because the car might have been hacked. Unfortunately, the distinction of malfunctions or security faults may often not be taken, e.g., because often it is rather difficult to determine the actual failure root.